Discovery vs. Documentation

The problem that I want to write about today has always been a problem, but in truth, the pandemic has made this problem substantially worse.  

In particular, I am worried about teams reverting back to the heavy use of artifacts such as product requirements documents (e.g. PRD’s).

I was afraid this would happen, and I tried to warn against this in many of my talks and interviews, and explicitly in the article Discovery When Working Remotely.

How did I know this was likely to happen?  

Because long before the pandemic, companies have been experimenting with different forms of remote work.  

And while some activities worked well with remote (like delivery), other activities struggled (like discovery), and there are only so many ways teams would deal with those challenges.

Note that this article is not trying to advocate for or against remote work.  There is no question there are many benefits especially regarding access to talent around the world, just as there is little question today that there are challenges.

This article is instead trying to help teams dealing with remote employees – especially with remote engineers – do better.

I understand where the desire for a return to old style requirements documents is coming from.  I’ve talked to so many developers that are just so fatigued trying to understand what it is that they need to build, that often they just throw up their hands and say, “just write down whatever you want, and we can get to work building it, but honestly I don’t care anymore.”

For several years now I have been trying to emphasize that when you cut through all the process noise and methods out there, there are really three things that matter when it comes to how strong product teams work:

• First, considering and addressing the risks up front (value, usability, feasibility and viability), before the engineers are asked to write a line of production code.
• Second, solving problems collaboratively in a give and take between product, design and engineering, rather than sequentially (product manager writing up requirements, the designer providing a design that satisfies those requirements, and engineers building to those requirements).
• Third, focusing on solving the actual customer and business problems (outcomes) and not just delivery features (output).

And the tragic thing is that when people get so frustrated and fatigued with the overhead of collaboration that they just give up and instead just ask for a specification, they lose all of this.

It’s essential to realize that a PRD addresses precisely none of these problems.

But here’s the thing: PRD’s are not inherently bad.  

If the product team does the necessary product discovery work to figure out a solution worth building, and then they add the step of documenting the details of what needs to be built so as to better communicate with remote engineers, that’s fine.

The problem is that in nearly every case I see, the PRD is written instead of the product discovery work, rather than after.

When a product manager is pressed to write a PRD with the detailed requirements, without doing the discovery work, they really have no idea if what they are describing will be something the customer will buy, or will be able to figure out how to use, or if the solution will work for the business, or if the engineers can even deliver the solution with the time, skills and technology available.

Without the prototyping of those ideas, and the back and forth with design and engineering to iterate and improve those ideas, and then the testing of those prototypes with users and customers, and with stakeholders to ensure the solutions will work for the business, it is just very unlikely that the necessary outcome will be achieved. 

And then we’re back to the resulting finger-pointing: engineers complaining they built what they were told; designers complaining they were already given the weak solution; and product managers complaining they just documented what they were told was needed.

The same is true with product roadmaps.  They are not inherently bad.  If the deliverables they are describing (the features and projects) are the result of product discovery work, then it’s simply a useful communication tool about what’s coming and when.

However, if the product roadmap of features and projects is created before or instead of the product discovery work, then we’re back to a bunch of commitments for things that likely won’t deliver the necessary outcomes.

(There is a different type of product roadmap that you may have read about from me or others called an outcome-based roadmap, that lists desired outcomes/problems to be solved rather than features and projects – but in my experience these are unfortunately the exception and not the rule).

So the key message from this article is that it is ok to spend the time to document the details to ease the pain of communication with your remote colleagues, but please don’t do that in lieu of your product discovery work.

Yes, it’s harder to collaborate when your colleagues are remote.  But with effort and continuous prototyping, you can do what you need to. 

Yes, it’s a pain to have to document in more detail than when the team is co-located.  But just think of this documentation step as a necessary tax.  It will slow you down a little, but it can help your engineering and QA to better understand the details.

You might be wondering if these same problems exist when instead of PRD’s the team just uses user stories?  Yes, much of what I describe is really a consequence of not doing product discovery.  However, PRD’s have a way of magnifying the problem.  I know this sounds odd, but as you probably know, user stories themselves are pretty useless.  But that in fact is what make them useful.  They make no pretense about describing requirements.  They are simply a placeholder for a discussion.  And that’s what’s good about them.  We need that conversation.

As soon as the product manager writes an actual PRD, there is a certain gravity to that document, and people are much less likely to challenge or question, than just assume the “requirements” are a given.

I have to admit I got pretty good at writing these PRD’s.  Sometimes I even found myself believing what I wrote myself, despite having no real evidence.

So why is this issue so important?  

Because if you believe that your business depends on continuous innovation, then you need to realize just how much damage you are doing to your chances.  Your engineers really are the most important thing.  

And when you just provide those engineers requirements instead of collaborating with them in determining what the right solution is, then you are effectively neutering those engineers.

And to those of you that are product leaders, this is really on you.

You need to decide how important continuous innovation is to your company and to your customers.  If you think you can get what you need by having product managers document PRD’s instead of product discovery, then you may as well just give up on innovation and hire Accenture.